@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/recipe.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.

  • For the tests[].python.python_version or tests[].requirements.run section of cuda-python output, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.

• If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

• ℹ️ 'Free Disk Space' is deprecated.
  Deprecated. Use workflow_settings.free_disk_space instead.
  Free up disk space before build.
  The following components can be cleaned up: apt, cache, docker.
  When set to true, only apt and cache are cleaned up.
  Set it to the full list to clean up all components.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/28073600391. Examine the logs at this URL for more detail.}

I think this migration is currently dropping CUDA 12.0/12.1 support for linux-aarch64, which we want to continue supporting on the 12.9 branch.

In the 12.9 branch, recipe/conda_build_config.yaml had cufile_supported as a variant with both True and False on aarch64, and the generated matrix included both linux_aarch64_cufile_supportedFalse... and linux_aarch64_cufile_supportedTrue... jobs. The False variants carried cuda-version >=12.0,<12.2a0, preserving the no-libcufile CUDA 12.0/12.1 ARM package path.

In this PR, recipe.yaml sets:

cufile_supported: aarch64

and the generated .ci_support files no longer include any cufile_supportedFalse aarch64 variants. Rendering a linux-aarch64 variant locally resolves only the cufile_supported path with cuda-version >=12.2,<13.0a0 and libcufile, so the aarch64 and not cufile_supported requirements appear to be unreachable.

Since CUDA 12.0/12.1 aarch64 packages are still intended to be supported for the 12.9 branch, I think cufile_supported needs to remain a real variant dimension in the v1/rattler recipe rather than a context value derived from aarch64.

@kkraus14 nice find! My mistake was assuming that these two are equivalent:

### Current change
# recipe.yaml
cufile_supported: ${{ False if aarch64 else True }}

### Previous support
# recipe.yaml
cufile_supported: ${{ cufile_supported }}

# conda_build_config.yaml
cufile_supported:
  - True
  - False  # [aarch64]

Just pushed the fix for this :)

Hm, CI didn't like some of those changes; I'll see what's going on in a bit

In a nutshell, cuda-nvcc-impl >=12.0,<12.2 has a dependency on gcc_linux-aarch64 <13. It's puzzling that I had to do this because meta.yaml in its current state provides green builds. But when I went to check a recent build, I found that there must be something funny going on with "False" being set. In this log, cuda-version is 12.9 and cufile_supported is "False" (https://github.com/conda-forge/cuda-python-feedstock/blob/12.9/recipe/meta.yaml#L57):

{
  "cuda-bindings-12.9.7-py313h306daec_0.conda": {
     "recipe": {
       "build_platform": "linux-64",
       "c_compiler": "gcc",
       "c_compiler_version": "14",
       "c_stdlib": "sysroot",
       "c_stdlib_version": "2.17",
       "channel_targets": "conda-forge main",
       "cufile_supported": "False",
       "cxx_compiler": "gxx",
       "cxx_compiler_version": "14",
       "numpy": "2",
       "python": "3.13.* *_cp313",
       "target_platform": "linux-aarch64"
     }
   }
}

It should certainly be older because of this line.

I suppose the work in this PR has uncovered a bug that's been hiding for a while, and pinning the compiler toolchain to an older version fixes it.

It reached a passing state 🥳

Hi! This is the friendly automated conda-forge-linting service.

I failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint --conda-forge . from the recipe directory. You can also examine the workflow logs for more detail.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/28112100995. Examine the logs at this URL for more detail.}

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/recipe.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.

  • For the tests[].python.python_version or tests[].requirements.run section of cuda-python output, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.

• If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/28142009176. Examine the logs at this URL for more detail.}

The linter's complaint of noarch: python is valid. However, Leo found a way to finagle recipe.yaml to give us parallel builds, but it comes at the cost of being able to use the python ${{ python_min }}.* suggestion.

Also looks like conda-forge is migrating from Azure to GHA (progress can be tracked here). Some repos have already adopted this change, and I could do that here with this change (I ran conda-smithy rerender on the recipe and auto-generated code didn't change):

diff --git a/conda-forge.yml b/conda-forge.yml
index 6e2b9a8..265aa72 100644
--- a/conda-forge.yml
+++ b/conda-forge.yml
@@ -1,7 +1,3 @@
-azure:
-  free_disk_space: true
-  settings_linux:
-    swapfile_size: 10GiB
 bot:
   abi_migration_branches:
   - '11.8'
@@ -23,3 +19,9 @@ noarch_platforms:
   - linux_64
   - linux_aarch64
   - win_64
+workflow_settings:
+  free_disk_space:
+    - value: "quick"
+      os: win
+    - value: "skip"
+      os: linux